Power Tools 1993 October

home *** CD-ROM | disk | FTP | other *** search

/ Power Tools 1993 October - Disc 2 / Power Tools (Disc 2)(October 1993)(HP).iso / hotlines / wsyhl / cosewp / cosewp.txt < prev next >

Wrap

Text File | 1993-06-20 | 34KB | 883 lines

WHITEPAPER ON OPEN SYSTEM PROCESS ACCELERATION: A Common Open Software Environment ________________________________________________________________ ______ June 8, 1993 OVERVIEW The common open software environment process came into being as six of the major UNIX System suppliers recognized that more effective cooperation was the key to meeting the demands of users for consistency and interoperability among software suppliers. While the initial announcement highlighted specific technology areas, the intent of the companies at the announcement was to accelerate the process by which open system software specifications are defined and submitted to recognized industry standard forums. Of course, this can be achieved only if the open system industry rallies around the proposed process acceleration. The purpose of this whitepaper is to lay out principles for such process acceleration and then to stimulate its adoption, benefiting customers and the industry through increased growth and innovation in the open system marketplace, in which the companies will continue to compete vigorously. The proposed process acceleration is intended to work with existing industry organizations to achieve faster consensus among more vendors. This whitepaper incorporates input from sources throughout the open software industry as a result of many reviews and intermediate drafts. Nevertheless some important points will have been overlooked and further evolution will be necessary for the open software industry to continue to improve its competitive postion. Feedback and conversation are encouraged through the avenue given at the end of this paper. The audience for this whitepaper includes OEM suppliers of open system software, independent software vendor suppliers, and end users, all of whom depend upon a fair open specification process and will benefit from any process acceleration. This whitepaper is also addressed to existing consortia, which have already made substantial contributions to the open systems process, and are in a perfect position to make even greater contributions with the support of this acceleration. This whitepaper has five major sections: First, a demonstration of how this process will expand choice for the customer of open system technology; Second, a proposed evolution of the existing process for specifying and and implementing open system software; Third, an explanation of how this process would work in practice; Fourth, a set of principles that apply within the open system industry; and Fifth, the stages in the life cycle of software technology. An Appendix describes some tactics for how to get involved. The paper proposes no new organizations. Existing organizations have accomplished much in the open systems arena and will benefit from these accelerated processes. This paper describes process and principles. It does not map these onto existing industry organizations, except for X/Open, whose specification, certification, and branding process are widely recognized as the most comprehensive and wide ranging in the industry. These make an excellent role model for the common open software environment process. This overview section concludes by breaking apart the phrase "common open software environment". Common. Users have made it clear that they need system software to be "plug and play" compatible between vendors. It is not enough for each software supplier to provide self-consistent software because that forces users either to make a long-term commitment to a single supplier or to face a major upheaval if they decide to change suppliers. The common open software environment process will make use of existing processes for specifying and deploying industry standard software to help users determine when their suppliers are providing compatible standard software and when they are not. Specifications and branding will be used to make this distinction clear. The primary benefits of common specifications for industry standard software are application portability and interoperability. As application writers observe that the same environment exists throughout the open system industry, and as they realize the benefit of stable, open specifications, they will be drawn to make more and more applications available. Open. One important use of "open" applies to the inclusive nature of the process for defining and then approving specifications. Such a process is open if ample opportunity exits for every voice to be heard. Openness in this sense is assured in the common open software environment process by the active solicitation from working groups for input from the industry, and by the use of existing consensus-based standards organizations, such as X/Open, for approving specifications. In order to achieve the consensus necessary for approving specifications, participants in the common open software environment process will need to encourage early and frequent review of draft specifications. A second important use of "open" applies to technology, where it has been used generally to signify a programming interface documented for others to use. Paticipants in the announcement of the common open software environment intended to clarify the definition of industry standard "open" technology. Under this clarification, a technology can be called industry standard open only if there is available a detailed written specification that governs correct behavior, and if implementation of complying software is unrestriced (e.g., it is not required to go to any particular supplier for the authorized software). Much current open system software already meets this definition, but some does not. As a way of demonstrating this new standard, X/Open is now applying its specification requirements to two technologies that formerly did not meet this test: OSF/Motif, and Novell NetWare UNIX Client. Vendors who implement to these specifications will be able to receive the associated X/Open brand no matter how they achieve the implementation, as long as they pass the necessary tests. Industry standard technology is well specified, is endorsed by a recognized standards organization and can be implemented to the specification without encumbrance. Source technology and sample implementations should be licensed readily and equitably to the industry with equal and early access for anyone. Software Environment. Software Environment means defining a standards-based environment for the building and deploying of complex applications in a hardware neutral way. Thus the common open software environment process results in products that give users a choice of hardware vendors that does not limit their software options. ________________________________________________________________ ______ FOUNDATION FOR CUSTOMER CHOICE With the success of open systems comes an expanding set of specifications of widely endorsed and broadly available programming interfaces. In the open system environment, customers are able to select a supplier of a particular solution without limiting their future options for choosing a different vendor for another solution. Many vendors in the open software industry are determined to define fully compatible software interfaces that customers will find on all platforms bearing a common brand for particular technologies, with brands controlled by an industry neutral standards organization. Like the companies that recently announced a proposed standard for HDTV, the members of the open software industry are banding together to propose standards for fully interoperable software. Then, like the suppliers of HDTV equipment, these vendors will compete vigorously against each other to sell their own particular product. More specifically, the products that result from the open software process will benefit developers, administrators and end users by expanding their choices now and for the future. For application developers, common open software products offer easier access to an expanded market. Developers will be able to focus on development needs, not on rationalizing middleware differences, because specifications and brands will assure them of the compatibility they require on systems from different vendors. The efficiency of application creators will increase along with innovation resulting in improved availability of application titles for end users. For system and network administrators, common open software products offer easier system and network expansion. Again, the specifications and brands will assure such administrators of the compatibility of systems from different vendors, thus accelerating the availability of single point multiplatform system management capability. For end users, they bring a consistent look and feel on the desktop. Interaction with the computer is intuitive and users can move from platform to platform with the confidence of familiarity. User productivity will increase through reduced training and education expense. The common environment will increase the number of available applications by simplifying application development, thus benefiting everyone. Finally, system integrators will have available to them more competitive choices for compatible systems, since any vendor's product that conforms to the appropriate specifications and carries the associated brand will provide equivalent functionality. Efficiencies realized in systems and network administration will be passed on to users as lower cost of support and reduced downtime. Thus all these customer constituencies will be free to select a vendor today without limiting their choices for tomorrow. The open software specifications provide the foundation for choice. The common open software environment process accelerates the adoption of standards. _________________________________________________________________ _____ ADDING A CATALYST TO THE OPEN SYSTEM PROCESS Technical innovation and user requirements have traditionally driven companies or groups of comanies to create solutions for the computing marketplace (see slide 1). Companies then competed for customers on the merits of their individual products. Sometimes this meant the products would work in multi-vendor environments and sometimes not, but in any event customers made their choice evident by their purchases. As de facto standards emerged from the choice of users, open system providers have negotiated specifications through standards organizations, and implementations of these specifications have become available across the majority of vendor platforms. Thus the amount of common open software has grown over time. In an effort to accelerate the availability of open system specifications, the common open software environment process describes a catalyst to the open system process. The catalyst is inserted in two phases of the open system process (see slide 2). First, at the point before formal submission of specifications to recognized industry bodies, working groups comprising representatives from the major interest groups in the open system industry will try to come quickly to consensus on a common recommendation. Then submission to the industry standards organization will allow the specification to be reviewed widely and approved more quickly. Second, in some cases cooperative development of an initial implementation can help to further coalesce the standard to promote compatible product solutions while accelerating time to market. A complete specification, with an implementation that supports development of a comprehensive test suite will be a catalyst to truly consistent APIs and behavior. This initial implementation will be licensed and made available readily and equitably to the industry at large. Both of these catalyst activities directly benefit the industry by reducing costs, and directly benefit users by reducing fragmentation. Acting only as a catalyst to the existing open system process, this proposal adds no new process stages or organizations. Existing open system initiatives such as OSF, POSIX, UI, and X/Open, which were formed to provide open specification forums, among other services, have laid a solid foundation for the current acceleration. Their best practices, such as requests for technology, member working groups and early access to code should be retained. The acceleration of the common open software environment process should make it easier to form working groups with broader representation than heretofore. The opportunity exists for a significant degree of synergy among these organizations . _________________________________________________________________ _____ HOW THE PROCESS WOULD WORK IN PRACTICE Central to the above process is achieving consensus to endorse a specification of particular technology behavior which then gets formalized at a vendor-neutral industry organization. For this to happen, some forums must exist for conversation at several levels. This section describes how that might work. Formation of ad hoc working groups. There are plenty of examples of successful multi-vendor solutions emerging from cooperation among open system vendors, and many of these have come from ANSI, UI, OSF and the X Consortium. The companies that announced the common open software environment spanned memebership of these organizations, and will work with these groups to come quickly to recommendations on open system specifications. Ad hoc working groups may be formed in some technologies as a way to get started on rapid progress while the existing industry infrastructure evolves to accommodate the breakdown of old barriers, while preserving the vital roles of existing organizations. There is a well-known trade-off between the size of a group and its ability to make rapid progress: smaller groups move more quickly. There is an inverse trade-off between the size of a group and an ability to reach approval in a broader community: results of a larger group effort gain broad approval more quickly because the direct involvement of more affected people exposes more problems sooner. The dilemma for the common open software environemnt is to form working groups sufficiently small to make rapid progress, and sufficiently large to account for the needs of a broad enough community. In part this can be accomplished if a smaller group takes the lead and solicits input from the broader community. Such working groups should therefore make themselves known by a public declaration, stating the problem on which they will focus, who the participants are, and how others can make their input known. In all cases recommendations of these working groups will be submitted for widespread review and finalization by recognized industry organizations. The composition of working groups should draw upon companies who can foster the success of the particular areas of technology, and is not limited to any specific set of companies. Preparation of formal specification and certification tests. Each working group is to be charged with producing a detailed formal specification that meets the open definition above, and that can be handed over for consideration by a certification and branding program at the close of the project. It is expected that the certification and branding program would be managed by a neutral industry group such as X/Open or the OMG. After the specification in finalized by a body such as X/Open, the working group members could also assist the standards body by providing it, either directly or indirectly, with a set of certification tests of sufficient completeness and quality to be used in a branding program. This body would evaluate the tests and coordinate as appropriate with the working group to reach the necessary test quality. After both the specification and the tests are accepted, then a complete branding program can begin, and individual vendors can cite conformance. The catalyst added by the common open software environment process is the discipline of requiring working groups to define and publish a draft specification, to provide test suites appropriate for branding, and to deliver an equitably licensed sample implementation. Sample implementation. Implementations of the specification could come to the marketplace in any number of ways. In some cases, industry members may want to cooperate in the development of an implementation of the specification. In others, one or more individual vendors might have implementations that others could license. Early availability of an implementation for use by multiple vendors can help achieve a solution with uniform compatibility and consistent behavior. In all cases, the common open software environment process requires a readily licensed sample implementation, available consistently to the industry. In any case, any vendor is free to develop its own implementation of the specification. Key points of common open software environment process There are five key points to the common open software environment process, reflecting how it works to provide a catalyst to the existing open system processes: 1) System suppliers come together in a working group to accelerate the recommendation of a draft specification, in a specific technology area. 2) Each draft specification will be submitted to a recognized industry body for broad review under establised processes, and, if accepted, will provide an unencumbered specification to which anyone can build an implementation. 3) One or more sample implementations should exist for each specification so that any interested vendor can exercise a make/buy decision. These implementations should be readily and equitably licensed to the industry. 4) Test suites should be available for certification and branding to the specification. 5) The process allows for different companies to participate for each technology area. _________________________________________________________________ _____ PRINCIPLES OF THE PROCESS This section describes the acceleration from the point of view of the participants: contributors to open system specifications and vendors of open system products. Contributors. To demonstrate a commitment to the principles of the common open software environment process, suppliers of open software technology would: - Accelerate multi-vendor definition of a draft specification ahead of the standards setting organization if necessary, by participating in ad hoc groups representing a critical mass of the open system industry. - Submit an unencumbered draft specification to an industry review and adoption process, and abide by the decisions of specification reviews. - Ensure their implementation conforms to a rigorous specification, certification, and branding mechanism. - Allow the building of unencumbered (no royalty) common behavior implementations to the specification. (Any necessary patent licenses should be openly licensable on reasonable terms and conditions consistent with standards organization practice.) - Encourage availability for open licensing of a sample implementation and certification test suites, including early access to source code to ensure rapid deployment. - Compete vigorously against each other on the basis of quality implementation, service, support, price, and other added value. Vendors. This same set of principles can be extended to what vendors of open system products can expect of the common open software environment process. Vendors of products that emerge from the common open software environment should expect: - That the specification will provide sufficient detail for them to build an implementation from scratch and that if they do so they will have no royalties to pay for use of the specification. - To be able to brand their implementations to the available specifications so that their customers know of their compatibility with other open system vendors. - That vendors, working together or separately on implementations based on the open sysetm specification, will be encouraged to make such implementations available for licensing, including early access. The principles in this section tend to apply differently during particular stages of the life cylcle of software, and open systems vendors engage in the process differently at different stages. The next section, taken together with the appendix, descibes how to be a full participant in the common open software environment process at all stages. ________________________________________________________________ ______ SOFTWARE LIFE CYCLE AND STAGES OF THE PROCESS Software technology passes through roughly four stages in its life cycle as it relates to the common open software environment process. Economics of product differentiation drive some software forward through these stages, as the value of differentiation decreases and the value of commonality increases. For the technology that ultimately becomes industry standard, the following four stages apply from inception through industry standardization: 1) Innovation - Vendors market a variety of solutions, often incompatible, trying to bring new function to market quickly, to meet a range of user requirements . 2) Common Direction - User demand for commonality drives innovative approaches into a more consistent direction . 3) Deployment - Vendors produce a draft specification, show industry endorsements, produce sample implementation(s), produce rigorous test suites. 4) Availability - Formal approved specification exists and certification branding is available. Vendors compete against each other on the basis of quality, service, price, and other added value. The remainder of this section comments more on each of these stages. The chart in slide 3 shows in which phase some sample technologies might fit in the taxonomy today. Innovation In the innovative phase, many different solutions may exist and users can select those that best meet their needs but may be constrained by incompatibility between vendors. Vendors accept the high risk of developing products because of the potential reward. Users accept a corresponding high risk because the technology may become obsolete. A basis of commonality has not been established. This may be because the marketplace has not yet clarified the scope and priority of user needs or decided which solutions best meet those needs. Or the technology may be one where a variety of different optimization points are needed to address a range of requirements. Thus both users and vendors benefit from innovation as long as the economics support it. The process described in this whitepaper addresses only the software that moves out of the innovative phase with a recognition of a demand for a common direction. Common Direction. As technology matures, users see the value in, for example, exchanging data between solutions from different vendors. Thus the value of commonality grows to equal the value of differentiation in elements of some technologies. In the face of this demand, vendors may confer to set a common direction, as a catalyst to the open system process. The common open software environment process allows for any group of vendors to initiate action toward a common direction, in fulfillment of a perceived user demand. It becomes a common direction only when a critical mass of vendors across the industry give it their support, while retaining their ability to address independently the broader range of differentiated user needs. Clearly, if sufficient vendors withhold support, their vote signals continued differentiation. Leadership of a common direction can come from any quarter, often initially through meetings of a few vendors. An action becomes a common direction only with an ample following made evident through public endorsements, and eventually through votes at industry organizations that formalize a specification. A common direction can take any of several forms: - Vendors could decide to integrate some existing technology and to write a new specification (e.g., the common desktop environment). - Vendors could decide to endorse a de facto standard (e.g., Motif). - Vendors could set up a work group to write a draft specification of a common set of Application Programming Interfaces. Deployment. In technologies where commonality has a critical mass of support, it behooves the industry to move as rapidly as possible to a specification, implementation, tests, and a brand. This can be accomplished in many different ways, ranging from a single company writing all components and licensing it to others, to a collection of cooperative development and test agreements between companies who decide to share the cost and the ownership (e.g., the common desktop environment). The deployment stage should include provisions for early access of specifications, implementations, and tests to facilitate broad, rapid deployment across the industry. Availablity. After a specification is approved and adequate test suites are available, a certification branding program can begin, and a support structure must exist for resolving ambiguities in the specification or in the tests. Thus vendors will compete against each other on the basis of product availability, quality, service, price, and other added value. All certified implementations would be permitted to carry the brand, and would be expected to exhibit the specified behavior. _________________________________________________________________ _____ CONCLUDING REMARKS The common open software environment process has been proposed as a way to accelerate the adoption of standards for the open system industry. Thus it is neither an initiative nor a group nor a club nor a consortium. The common open software environment process is an open system process, a set of principles, a commitment to catalyze, and a mind set to accelerate. The purpose of this whitepapaer is - to lay out the principles for a common open software environment in which contributors and vendors cooperate for the growth of the industry and for the benefit of users, and - To describe a process that embodies this cooperation. Now the task is to build support for these principles and processes. The UniForum Association has volunteered to be a focal point for your feedback. Please contact Ed Palmer at 408-986-8840 ex. 12, or by email to cose@uniforum.org. ________________________________________________________________ ______ APPENDIX Tactical Scenarios The body of this paper outlines some principles and strategies for the common open software environment process. These are necessary but not sufficient to document how vendors might engage for the best advantage to themselves and to open systems. This appendix proposes a tactical response for several scenarios, with a focus on setting common directions, the catalyst in the common open software environment process. 1. Starting a New Common Direction Activity Suppose your company has some state of the art expertise in a technology in which commonality will be required in the near future for its market to continue to grow. How should you introduce a common direction, and how can it follow the common open software environment process? Here are some suggested steps: 1) Test your assessment of the business opportunity and the technology against the principles described in this paper. a. Demand for commonality b. Key multi-vendor agreement c. Commitment to open specification d. Availability of sample implementation and tests 2) Become familiar with the principles of the common open software environment process as described in this document, and engage others on the basis of these principles. 3) Identify and engage other companies. Work with existing working groups or use an RFP or your own networks to find like-minded vendors. Seek to build critical mass of both large and small vendors, while keeping your group small enough to be manageable. 2. Conducting a Common Direction Setting Activity Suppose there is now a group formed which intends to set a common direction, and you are one of the initial memebers. By voluntarily participating in a common direction setting group in the open software industry, you assume responsibility for accelerating a technology to a specification that will be widely adopted and implemented. Such adoption can only happen if the requirements of vendors both inside and outside the direction setting group are adequately accounted for. Accordingly, the following tactics are directed at both rapid progress and broad participation. Here are some suggested steps: 1) Seek input from companies not included in your small group to be certain that all requirements are understood and no opportunities for input are overlooked. 2) Identify an appropriate vendor-neutral standards organization and begin conversation with them regarding your intent to set common direction and to build a draft specification, if applicable. 3) At an appropriate time make a press announcement citing the common open software environment process and seek public endorsement from a broad spectrum of open system vendors for the direction you are setting, including others who have endorsed the common open software environment process. 4) Prepare a draft specification for submission to the selected standards organization. Adjust the specification as needed to accommodate the review process. Work towards a passing vote through member consensus. 5) Follow through with you implementation of the specification. Engage other companies in a joint cooperative development, if desired. Provide technology licenses, including early access, to other vendors. 6) Facilitate broad availability of implementations to the specification. 3. Joining an Existing Direction Setting Activity Suppose a group of companies has made a public announcement of a direction-setting activity and you wish to be involved. You agree that commonality has become necessary in this technology, and it is a vital part of the future of your business. Accordingly you wish to facilitate the adoption of a common direction, and you wish to have your own product implementation in the marketplace as early as possible. How can you position your company either to influence the common direction, or at least to take maximum advantage of it? Here are some suggested steps: 1) Contact one or more of the companies that announced the common direction setting activity and request status reports. 2) Make your requirements known to the participants in the common direction setting group. 3) If your wish to influence the common direction, prepare a position paper or presentation. Approach one or more of the companies to provide input, recognizing that the companies will be looking for ways to accelerate the definition of a common direction, and recognizing as well that not all proposals can be incorporated. Proposals that either bring missing technology or add significant contribution within the scope of the project would be the most favorably received. 4) Seek to be involved in any press releases that come from the common direction group, stating your involvement with and endorsement of the activity. 5) Contact the selected vendor-neutral standards organization and register with them at a level appropriate to your desire for review. Participate in their review and adoption processes. 6) Consider developing a sample implementation, either alone or working with other companies. Alternately, take all available early access of source code and proceed aggressively to build you own product implementation. 4. Other Stages of Software Life Cycle This appendix has focused on the setting of common directions, which is a primary catalyst activity in the common open software environment process. Similar steps can be taken to engage with other vendors in the evolution of technology in all other stages as well. ________________________________________________________________ ______